home *** CD-ROM | disk | FTP | other *** search
- Date: Mon, 1 Aug 94 02:03 CDT
- From: ekl@sdf.lonestar.org (Evan K. Langlois)
- To: gem-list@world.std.com
- Subject: Re: GEM List
- Precedence: bulk
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- Toolboxes are not the only place background windows should be enforced. Make
- it so that if a user creates a window with your library, they have the
- option to use WF_BEVENT. If they are not using the right TOS version, then
- handle the WF_BEVENT bit yourself!
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- Why not set the WF_BEVENT bit for all windows. Handle topping yourself,
- and handle changing tops to clicks yourself. The only restriction here
- is that a drag cannot be done from a backrgund window unless the OS
- has WF_BEVENT.
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- assed coder. TRY something for a change, rather than coming up with excuses
- to get out of everything before even trying it.
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- Just because you try it, and it works, does NOT mean that it is portable, nor
- does it mean it is good programming style (and I don't mean the position of
- your brackets, I mean inter-application cooperation).
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- gadgets. XAES doesn't *force* you to do anything. XAES is all about
- *choices*, not being forced to do anything you don't want it to.
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- It should look and feel like standard GEM, and actually USE standard GEM
- (no faking any of it!). Only if the user specifically sets a certain
- option should the new gadgets be used. Maybe something like :
-
- SomeApp.Motif.Gadgets: On
-
- Otherwise, don't!
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- Have you used WinX? They have different window gadgets, and yet, I don't
- hear anyone complaining.
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- No, the gadgets are NOT different! You can have the arrows positioned
- differently, but this is system-wide! Not per-application (although
- anyone that really wants to, could make it per application). A system
- wide, and minor change at that, is OK. But switching from Gem gadgets to
- Motif Widgets for just one app is gonna irritate some people. I would
- suggest only using them for the above app-defs line, otherwise, pass
- some GEM Gadgets to your wind_create call eh?
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- I would have to see this to believe it. MiNT itself is slower than snot.
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- What tests have you done? MiNT .95b was about 2-3% slower than TOS 1.62
- when running over TOS 1.62. I used numerous benchmarks. MiNT has been
- getting faster and more compatible ever since. When 1.11 comes out, it
- will be freely available. You can see for yourself when its released just
- how fast it is. How fast can your system print text? On my MiNT system
- I get about 8000 cps! With scrolling, using Cconws or Fwrite, in 80
- character chunks. It would go faster if I just used one long 32K write
- and timed it! If you need help using MiNT, email me. You must be doing
- something weird with it (not surprising considering your abuse of the AES)
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- Put the new AES on top of it and things really go downhill. If you'd like to
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- Any AES will slow the system since the AES does a constant polling for
- events which eats up CPU time. Something your own programs do! A non-polling
- AES will be released at a later date.
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- Better yet, do some benchmarks and give some *hard* facts, numbers that
- can be *duplicated* by anyone. Try something like GemBench and Speedometer
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- I don't currently have either of those programs right now, but GemBench
- used to give me 96-99% with MiNT .95, and with 1.10+ its even more efficient,
- especially in BIOS IO. Since I now have an AdSpeed, posting tests would
- not be an accurate comparison anymore (which is why I posted results for
- MiNT .95, which is also freely available in binary form- try it yourself).
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- Atari got their head out of their .... with this new MultiTOS (at least in
- terms of speed, not usability -- that is a completely different issue.)
- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
- Flame on:
- The new MultiTOS is faster because it uses device drivers and Fselect(), or
- something similar instead of polling the hardware. Fselect() is like
- evnt_multi for file handles. You yourself have turned evnt_multi into
- a polling call by using 0ms timers. Your programs will still be VERY slow
- under any operating system because you STILL haven't gotten your head out
- of YOUR ASS and realized that polling is a bad programming practice. You
- talk alot about others and ATARI, but you are doing the exact same thing.
- In fact, what do is worse, because there is a way around it. Until MiNT
- came along, ATARI didn't have a better way, or even a reason. Maybe instead
- of insulting a lot of people that are really doing wonders for the OS,
- you should shut the hell up because you don't know what you are talking
- about, and that goes for MiNT -AND- how you think the AES works and your
- demand for benchmarks (which can't show half of what you ask anyway).
- Flame off:
-
- vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
- I'm not sure where you got that figure. You must have lots of OTHER
- programs contributing to that figure. And don't use Warp9 with MiNT
- either - that steals MORE system time than MiNT does. You can take two
- identicle systems, one running MiNT and one running Warp9. The MiNT
- one will do graphics slow, and CPU operations fast. The Warp9 one will
- do graphics fast, and CPU operations will be slower than MiNT! If you
- combine MiNT and NVDI, you get a nice fast system all-around that can
- handle multiple tasks. See :
- PID PPID PRI CURPRI STATUS SIZE TIME COMMAND
- 000 000 0 0 Wait 46800 01:13.43 MiNT
- 003 000 0 0 Ready 136864 09:25.54 vconsd
- 005 000 0 0 Ready 37328 18:21.51 ttyd0d
- 007 000 0 0 Sleep 98992 00:00.14 sh
- 009 000 0 -3 Ready 76576 01:51:12 top
- 010 000 0 0 Sleep 98992 00:00.98 sh
- 013 000 0 0 Wait 100336 00:08.63 GEM
- 014 013 0 -1 Ready 237488 13:09:43 TOSWIN_W
- 016 000 0 0 Sleep 237040 00:28.45 bash
- 019 000 0 0 Sleep 35984 00:06.82 wterm
- 020 019 0 0 Sleep 40688 09:16:56 wterm
- 110 000 0 0 Sleep 77344 01:55.52 me
- 123 016 0 -5 Ready 29376 00:00.63 ps
-
- And I'm not doing that much multitasking right now! I'm not very busy.
- Normally I've got 2 or 3 editors going and a couple file viewers while
- a zmodem is going. And there is no slowdown. I have to run about 2
- or 3 archivers and the AES before getting a "slow as snot" speed. Or
- GNU C - the constant disk access makes things jump. 16Mhz system.
-
-